Commodore Free 18/Commodore_Free_Issue_18_2008_Commodore_Computer_Club.d64/t.aztec c

Text File | 2023-02-26 | 7KB | 214 lines

u
Aztec C for C64 & Time source code
(C) Copyright 2008 Bill Buckels All
Rights Reserved.

The TIME program for the C 64 contains
a completely rewritten English Language
version of an application that I
originally developed & published for
Apple IIe in 1991. The formal title of
this program is "What Time Is It?".

The goal of the application is to
teach Elementary School Children how
to tell time. Regardless, my own goal
in producing this program was to
provide a full-blown application that
demonstrates what a seasoned expert
Programmer can do in the Aztec C
Environment for the C 64.

Now if all you are in this for is run
programs and not to make them the TIME
directory like all my other program
directories contains the finished
programs including a disk image called
time.d64. These programs are preloaded
on the disk image and run nicely in
the vice emulator. If you are using
these in WinVICE remember that while
graphics load quickly in Warp Mode,
the sound routines are time-based and
you should take your emulator out-of
Warp Mode for proper sound playback
and time-based events.

Introduction:
If you are reading this but have not
reviewed all of the samples and all
the projects in this programming
environment please do not be offended
if most of this goes completely over
your head, or worse yet sounds like a
nattering old man (which it should if
it's flying high enough, since that
was my intent). Take comfort in the
fact that I am giving you all the
source code and graphics images that I
used to produce the TIME application.
All this is completely transparent.
There are no trade secrets here and no
TIME deadlines so take your TIME and
enjoy the confusion because it's part
of the game. It feels so good when you
finally understand, for a moment...
'nuff said.

So let's get started and talk about
the architecture and I am assuming
that you have read the other make files
& gained an understanding that memory
management and mapping is "Job One".

Balancing the TIME Overlays:
I really enjoyed this part. Some of
you can imagine how I hurried through
getting all my samples and library
routines written and tested so I could
actually do something more-or-less
meaningful.

I wondered myself at times whether I
would be able to fit all the stuff I
needed to into memory. My work on this
particular application on the Apple
IIe using Aztec C was in the PRODOS
128K environment which allowed me To
store data in auxiliary memory. Even
in that environment which is about the
same size in conventional memory as
this one, I needed to break down the
Apple IIe version of TIME into more
overlays than I did here and to keep
the graphics data in upper memory...
an option I don't have here.

So when I did all this and it just
barely fit I knew I could show the
rest of you how far this can go
without breaking, Like I said above;
memory management and mapping is "Job
One" and showing someone what can be
done makes the job fun.

You should have already figured-out
from my other programs that I have
been playing around with program
memory holes, and sticking data into
bits of memory that I couldn't run my
programs in.

This is the way we do it. You should
also have figured-out by now that the
linker outputs the code and data
sizes, and that my make files can be
redirected to disk file so you can
review errors and do something about
them, or to examine actual data and
code size and adjust the memory usage
until there is barely any wasted
space.

When I do overlays I am always
trading-off what to put into the main
(root) module and what to link into
the overlays. If the main module gets
too bloated and the overlay wipes-out
the upper ram the program will finish
but never get back to the BASIC
prompt. My goal is always to get the
user back to the OS whether I program
for Windows, Linux, MS-DOS, Apple IIe
ProDOS, or the C64. One must therefore
consider all the overlays at once and
realize where one must put what and
when to discard and when not to.

In making TIME fit into SPACE I
created some pretty neat tools to help
save memory, and kept the code that I
could in the main module, and the code
that I couldn't in the overlays.

I run-length encoded my graphics and
re-used buffers as well. The C64 disk
drive is notoriously slow, so it is
bad enough that I needed to read these
overlays from disk but it would have
been much worse if I needed to read
additional graphics from disk, or
worse yet, to read more overlays (like
I needed to on the Apple IIe).

My comments are pretty good in the
TIME modules, but sorry kids, they are
intended for experts. So become one
yourself if you aren't already and
read the code and the MAKEFILE and run
the thing and have some fun with it.

'Nuff Said on the balancing of
overlays... some additional eulogies
on the topic are in the TIME source
code.

Using The Graphics and Sound Routines
If you have looked at my graphics
routines you know by now that I could
have gone much further, but that was
never my goal. I just wanted to have a
little fun with this old compiler and
show-off a little bit and leave the
field wide-open for competition.

I also could have optimized a little
further, or a lot further. But I
already know where all this breaks and
by now I think I got some of my
money's worth back on my original
purchase price in enjoyment.

Part of my goal was to showcase the
B64NAT.LIB in all of this. I think
that the C64 routines that I am
leaving you with are better than what
I did on the Apple. The sound is
better of course and the game play is
without doubt the same since the
processor is the same. The memory
saving technique of run length
encoding can be taken further, but I
kept it simple. Still, by comparison
the C64 stuff is easily as robust as
the Apple IIe equivalent of using
bitmap graphics from upper memory. I
am satisfied and can now leave this
alone. So by all means change the
code, and have some fun yourself.

My selection of multicolour mode was
deliberate. The graphics are simple
since I originally drew then for the
Apple II to avoid aliasing which
effectively puts them somewhere close
the same coarse resolution as on the
C64. There are strange considerations
when comparing low resolution graphics
on the IBM-PC and Apple IIe and C64
which I have discussed in length in my
Wikipedia articles etc. But the common
denominator that I mostly went with
was 4 Colors, and 2 of them being
Black and White, with the other two
mainly Red and Blue, & I will leave the
rest for you to figure-out on your own.

Read the code, run the program and
have fun!

Over and Out.

Bill Buckels February 25, 2008